This patch stores the metadata about the Node.js binary
into the SnapshotData and adds fields denoting how the
snapshot was generated, on what platform it was
generated as well as the V8 cached data version flag.
Instead of simply crashing when the metadata doesn't
match, Node.js now prints an error message and exit with
1 for the customized snapshot, or ignore the snapshot
and start from scratch if it's the default one.

PR-URL: nodejs#44132
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>

By default, the debugger would query the specified inspector
sever port to see if it's available before starting the server,
and it would keep retrying until a timeout (previously 9999 ms)
is reached. This timeout seems to be longer than necessary. This
patch decreases the timeout to 3 seconds.

PR-URL: nodejs#44359
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Richard Lau <rlau@redhat.com>

sequential/test-child-process-execsync and
parallel/test-child-process-spawnsync-timeout are both flaky
on azure Windows machines, where it may take longer for Node.js
to launch and receive output from child processes. These tests
work by spawning a child processes that is supposed to sleep
for a long time, but the option is configured so that Node.js
would terminate them early when a shorter timeout is reached.
Then the tests assert that the time taken for the whole thing
is shorter than the specified sleep time (meaning the process
don't actually get to sleep for that long). To make the tests
less brittle on azure Windows, this patch raises the sleep
times in those tests on Windows platform, so that the overhead
can be taken into account there.

PR-URL: nodejs#44375
Refs: nodejs/build#3014
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Nitzan Uziely <linkgoron@gmail.com>

The original heap prof tests can take too long to complete on
azure Windows machines, resulting in timeouts. Split them into
smaller tests and move them into the parallel directory to
speed up the execution.

PR-URL: nodejs#44388
Refs: nodejs/reliability#356
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Previously the tests required that Node.js finish the initialization
of the watchdog thread and fires the timeout within 100ms, which
can be difficult on certain systems under load. This patch
relaxes the requirement to 2000ms. If there is a bug and the
timeout can actually be escaped, raising the timeout to 2000ms
would not make a difference anyway.

PR-URL: nodejs#44433
Refs: nodejs/reliability#333
Refs: nodejs/reliability#361
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>

On Windows it might take too long for the parent to start the
communication with a child process, so by the time the parent
starts its own timer, the child process might have already
completed running, and the parent in those tests won't have a
chance to terminate these child processes after the timeout.
To address this issue, raise the time for which the child is
supposed to run to make sure that the parent starts
its own timer before the child terminates in the tests.
Also, split the test into smaller ones to reduce the overhead.

PR-URL: nodejs#44390
Refs: nodejs/reliability#356
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>

The test previously created two fs.promises.open calls on the
same file with w+ back-to-back, and one of them could fail
when checking the contents of that file if the other happened
to be opening the file for write. Split them into different
tests (with different tmpdir) to avoid the race.

PR-URL: nodejs#44380
Refs: nodejs/reliability#354
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>